Add .NET SDK with dependency-injection integration (Aayush Mishra) - #9
Open
aayushmishraaa wants to merge 1 commit into
Open
Add .NET SDK with dependency-injection integration (Aayush Mishra)#9aayushmishraaa wants to merge 1 commit into
aayushmishraaa wants to merge 1 commit into
Conversation
A .NET client that registers through IHttpClientFactory, so pooling, resilience
and telemetry come from the host application rather than being reinvented inside
the library. AddSuperDocs returns the IHttpClientBuilder, and the worker sample
attaches AddStandardResilienceHandler to it.
Multi-targets net10.0 and net8.0 — the current LTS and the previous one, because
enterprise Microsoft-stack teams are frequently a release behind and are exactly
the people who cannot upgrade on someone else's schedule.
Source-generated JSON throughout, nullable enabled, every method async with a
CancellationToken, and no synchronous surface at all. Builds 0 warnings / 0
errors on both frameworks under TreatWarningsAsErrors with AnalysisLevel
latest-all. 38 tests, no API key, no network. Packs deterministically with
symbols; two clean rebuilds produce a byte-identical assembly.
The SDK absorbs four API behaviours so consumers never meet them, each found by
calling the live API rather than by reading docs:
- Proposed changes are encoded two different ways depending on how you fetch
them. metadata.pending_changes returns objects; the SSE and
intermediate_responses paths return a JSON-encoded string. Guidance calling
the second parse universal is true of one path and false of the other.
- A large edit arrives in several approval rounds. ReviewAsync drives the whole
review; approving once and waiting for completion polls forever.
- An unknown `operation` value used to make the whole change fail to
deserialise and vanish from the review — a reviewer would approve a batch
without being shown one of its edits.
- The upload field is file_base64, not content_base64.
Includes a worker-service sample that watches a folder and produces branded
documents, runnable from a clean clone with only SUPERDOCS_API_KEY set.
AutoApprove defaults to false: an unattended worker that approves its own edits
has no human gate, and a sample that pretended otherwise would teach the wrong
shape.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Aayush Mishra
A .NET client for the SuperDocs API that registers in one line through
IHttpClientFactory, so connection pooling, resilience and telemetry come from the host application rather than being reinvented inside the library. Includes a worker-service sample that watches a folder and produces branded documents.Built for the SuperDocs engineer task.
What's in it
AddSuperDocs(configuration)returns theIHttpClientBuilder, soAddStandardResilienceHandler()is the host's call, not the SDK'sasyncwith aCancellationToken, and no synchronous surface at all — a blocking wrapper is the classic deadlock, so the library doesn't offer oneTreatWarningsAsErrors+AnalysisLevel latest-allFour API behaviours it absorbs
Each found by calling the live API rather than reading docs, so consumers don't meet them:
metadata.pending_changesreturns real objects; the SSE andintermediate_responsespaths return a JSON-encoded string. Guidance describing the second parse as universal is true of one path and false of the other — apply it to the polling path and you throw, skip it on streaming and you get nothing.ReviewAsyncdrives the whole review; approving once and waiting for completion polls forever (I watched it reach 146 requests).operationvalue used to make the entire change fail to deserialise and vanish silently — a reviewer would approve a batch without being shown one of its edits. It now degrades toUnknownand stays visible.file_base64, notcontent_base64.Sample
samples/SuperDocs.Worker.Sampleruns from a clean clone with onlySUPERDOCS_API_KEYset.AutoApprovedefaults to false — an unattended worker that approves its own edits has no human gate, and a sample that pretended otherwise would teach the wrong shape.Limitations, stated in the README
No large-upload (presigned) path, no multi-document sessions, no template wrapping, a guessed 20-round review bound, and an SSE parser that skips frames it doesn't recognise.